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DETAILED ACTION 
Information Disclosure Statement 

1 . The listing of references in the specification is not a proper information disclosure 
statement. 37 CFR 1.98(b) requires a list of all patents, publications, or other 
information submitted for consideration by the Office, and MPEP § 609 A(1) states, "the. 
list may not be incorporated into the specification but must be submitted in a separate 
paper." Therefore, unless the references have been cited by the examiner on form 
PTO-892, they have not been considered. 

Claim Rejections - 35 USC §112 

2. The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

3. Claims 1, 9, 14, 17, 20 and 28 are rejected under 35 U.S.C. 112, second 
paragraph, as being indefinite and failing to point out and distinctly claim the subject 
matter which the applicant regards as the invention. 

Regarding Claims 1 , 20 and 28 the disclosure does not clearly define the phrase 
"stability of a project." The phrase stability of a project is used in a plurality of ways and 
interchangeably with the following terms status of a project, stability of a project's 
organization and content, and the progress of a project rendering the phrase 
inconsistent, vague and indifferent. Further the phrase stability of a project could 
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include a plurality of concepts including but not limited to financial, resource, process, 
tools, platforms, client, customer or any of a number of other project related stability 
factors. The examiner read stability of a project to mean the progress of a project as 
disclosed in the title of the invention. 

Regarding Claim 9 the disclosure does not clearly define the phrase 
"development." The phrase development as claimed can read to include a plurality of 
concepts including but not limited to the organization/resources responsible for 
developing a project, the act, process, or result of developing (code, documents, tests, 
analysis, etc.), the status/progress of a project, or the state of being developed 
thereby making the term "development" as claimed vague and indefinite. The examiner 
read development to mean the progress of a project. 

Regarding Claim 14 the disclosure does not clearly define the phrase "variable 
dependency." The phrase variable dependency as claimed can read to include a 
plurality of concepts including but not limited to a dependent relations between variables 
(metrics), metrics whose dependencies' change/vary overtime, between projects, 
project progress results which vary over time or on dependent on other progress 
parameter analysis results or an almost unlimited number of variable dependencies 
thereby making the term "variable dependency" as claimed vague and indefinite. The 
examiner read variable dependency to mean any of the items discussed above. 
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Regarding Claim 17 the disclosure does not clearly define the phrase "object 
oriented format." The phrase object oriented format as claimed can read to include a 
plurality of concepts including but not limited to an object-oriented architecture, object- 
oriented data store, object-oriented analysis and design, object-oriented programming 
languages, object-oriented modeling languages or an almost unlimited number of 
"formats" thereby making the term "object oriented format" as claimed vague and 
indefinite. The examiner read object oriented format to mean any of the items 
discussed above. 

Claim Rejections - 35 USC § 101 

4. Claims 1-19 are rejected under 35 U.S.C. 101 because the claimed invention is 
directed to non-statutory subject matter. 

The basis of this rejection is set forth in a two-prong test of: 

(1) whether the invention is within the technological arts; and 

(2) whether the invention produces a useful, concrete, and tangible result. 

For a claimed invention to be statutory, the claimed invention must be within the 
technological arts. Mere ideas in the abstract (i.e., abstract idea, law of nature, natural 
phenomena) that do not apply, involve, use, or advance the technological arts fail to 
promote the "progress of science and the useful arts" (i.e., the physical sciences as 
opposed to social sciences, for example) and therefore are found to be non-statutory 
subject matter. For a process claim to pass muster, the recited process must somehow 
apply, involve, use, or advance the technological arts. 
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Regarding Claims 1-19, claims 1-19 only recite an abstract idea. The recited 
method for determining the stability of a project does not apply, involve, or use the 
technological arts since all of the recited steps can be performed in the mind of the user 
or by use of a pencil and paper. 

Additionally, for a claimed invention to be statutory, the claimed invention must 
produce a useful, concrete, and tangible result. The claimed invention, as a whole, is 
not within the technological art as explained above claims 1-19 are deemed to be 
directed to non-statutory subject matter. 

Claim Rejections - 35 USC § 103 

5. The following is a quotation of 35 U.S.C. 103(a) which fomris the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

6. Claims 1-4, 6-9, 12-15 and 18-28 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Paul et al., Software Metrics Knowledge and Databases for Project 
Management (January 1999) in view of Minkiewicz et al., U.S. Patent 6,073,107. 

Regarding Claims 1, 20 and 28 Paul et al. teaches method and system for 
analyzing and assessing the progress of a project (employing software metrics in the 
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efficient execution and management of projects), the method and system further 
comprising: 

the selection and use of a plurality of metrics (parameters), including but not 
limited to project progress metrics, and their associated data (Section 2 - Test & 
Evaluation Metrics Data, Columns 3-4). 

the use of data integration and analytical techniques, including multiple 
regression analysis, on a plurality of metrics in order to conduct quality and risk 
assessments (project status. Section 2.1.2 Regression and Principal Component 
Analysis, Page 260; Figure 3). 

a plurality of techniques, including regression analysis and principal component 
analysis, to identify the correlation among a plurality of metrics thereby determining their 
interdependencies (Section 2.1.2, Page 260). 

Paul et al. does not expressly state the use or computation of correlation 
coefficients. 

Official notice is taken that it is old and well known in the art that regression 
analysis is a common and well known technique for detemnining the relationship 
between several independent or predictor variables and a dependent or criterion 
variable and that the degree to which two or more predictors are related to the 
dependent variable is expressed in the correlation coefficient. The regressions 
analysis, further comprising the use of correlation coefficients, providing knowledge of 
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the interdependencies can be crucial in predicting the extent perturbations brought 
about by any failures or changes in the project (Section 2.1 .2, Page 260). 

It would have been obvious to one skilled in the art at the time of the invention 
that the method and system for analyzing and assessing the progress of a project 
wherein analyzing the metrics was conducted through the use of statistical regression 
analysis techniques, as taught by Paul et al., would have included the calculation of 
correlation coefficients. The benefit of such regression analysis being to further assist 
project managers with the critical management decisions regarding risk and quality 
during the life cycle of a software project (Section 3 - Conclusion, Page 263). 

Regarding Claims 2 and 21 Paul et al. teaches the use of a plurality of project 
progress and product metrics for use in analyzing and assessing the progress of a 
project. Further Paul et al. teaches the use of classification trees (Section 2.1.4, Page 
261-262) for the classifying of a plurality of metrics (Column 1 , Paragraph 2, Page 262). 

Paul et al. does not teach the use of the specific project progress parameters as 
claimed. 

Minkiewicz et al. teaches a method and system for analyzing and assessing the 
progress of a project (Abstract). Minkiewicz et al. further teaches the representation of 
software project components whose structure is represented as a tree. More 
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specifically Minkiewicz et al. teaches the use of a plurality of metrics (measures) 
associated with the tree including, but not limited to: the average number of children per 
nodes (leaves) and the number of top level nodes (branches) as a means for analyzing 
and assessing the size and complexity of the software project in order to 
predict/measure the progress of a project (Figure 13; Column 2. Lines 9-16; Column 7, 
Lines 24-44; Column 8, Lines 7-12). , 

It would have been obvious to one skilled in the art at the time of the invention 
that the method and system for analyzing and assessing the progress of a project as 
taught by Paul et al. would benefit from the inclusion of the project progress metrics for 
detemriining the size and complexity of a software project as taught by Minkiewicz et al. 
thereby adding depth and accuracy to the analysis in the form of providing additional 
project progress metrics. The resultant analysis and assessment providing a more 
accurate and complete understanding of the progress of a project therefore assisting 
project managers with the critical management decisions regarding risk and quality 
during the life cycle of a project (Section 3 - Conclusion, Page 263). 

Regarding Claims 3 and 22 Paul et al. does not expressly teach the regression 
equations to be used when analyzing the collected metrics data. 

Official notice is taken that the regression equations as claimed are old and well 
known in the art as being among a plurality of equations and approaches available for 
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statistical regression analysis. Accordingly, it would have been obvious to one skilled in 
the art at the time of the invention that the method and system for analyzing and 
assessing the progress of a project as taught by Paul et al. would benefit from the use 
of any of the plurality of well known and accepted regression analysis techniques and 
equations, including the equations as claimed, when analyzing the metric data collected 
in order to provide insight into the progress of a project. 

Regarding Claims 4 and 23 Paul et al. teaches the use of a database for the 
collection, storage and analysis of software project progress parameters (metrics; 
Paragraph 1, Page 256). 

While Paul et al. does not expressly teach the structure of the collected metric 
data as being branches and leaves (tree) his extensive use of graphs (classification 
trees, influence diagrams/graphs and entity-relationship diagrams) - a tree being by 
definition a connected acyclic graph, teaches the use of graphs for structuring data 
thereby resulting in models which are straightfonA/ard to build and interpret (Paragraph 
2, Page 262). 

Minkiewicz et al. teaches metric data being structured as branches and leaves 
(tree). Further the use of a tree data structure is old and well known in the art as a 
means representing interrelated data and other information in a straightforward manner. 
Accordingly, it would have been obvious to one skilled in the art at the time of the 
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invention that the method and system for analyzing and assessing the progress of a 
project as taught by Paul et al. would benefit from the use of graphs (trees) as a means 
for structuring complex data so it maybe more readily understood and acted upon in 
view of the teachings of Minkiewicz et al. 

Paul et al. does not expressly teach the updating of at least one database. 



Official notice is taken that is well known in the art that database methods and 
systems act on the data stored within them. More specifically a database system (DBS) 
or database management system (DBMS) is defined as consisting of a collection of 
interrelated and persistent data and a set of application programs used to access, 
update and manage that data (which form the data management system). The goal of a 
DBS is to provide an environment that is both convenient and efficient to use in 
retrieving and storing information in the database and provide concurrency control if the 
system is shared by users. 

It would have been obvious to one skilled in the art at the time of the invention 
that the software metrics knowledge and databases for project management 
(specifically the software metrics database) taught by Paul et al. would by definition 
manipulate the plurality of data it encompasses as part of the overall method and 
system for analyzing and assessing the progress of a project thereby providing a 
convenient and efficient means for storing and retrieving information in the database. 
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Regarding Claims 6 and 25 Paul et al. teaches the collection and analysis of 
requirements traceability and stability metrics (Column 2, Paragraph 5, Page 256). 

Paul et al. does not teach the modeling of a software requirements document 
having the structure of a tree (branches and leaves). 

Official notice is taken that it is old and well known in the art to represent 
documents and other project components utilizing a basic tree structure wherein nodes 
(leaves and branches) represent the structure and content of the document or 
component. Well known standards for structure document representation include, but 
are not limited to: Standardized Generalized Markup Language (SGML), extensible 
Markup Language (XML) and Microsoft's Document Object Model (DOM). The purpose 
of these standards is to provide an agreed upon and structured format for representing 
the structure and content of a document. 

Further it is well known in the art that collecting and analyzing the lifecycle 
(history) of project components, including requirements and other documents, through 
the use of metrics (number of documents, number of revisions per document/section, 
number of revisions per person, per time interval and the like) provides essential 
information regarding the current status and progress of the component being analyzed. 
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It would have been obvious to one skilled in the art at the time of the invention 
that the method and system for analyzing and assessing the progress of a project as 
taught by Paul et al. would have benefited from the additional insight provided by the 
inclusion of project progress metrics relating to the project's requirements document. 
Further the use of a the structured and standardized document models would have 
benefited the method and system for analyzing and assessing the progress of a project, 
as taught by Paul et al., by providing a structured means for collecting and analyzing 
project progress parameters associated with the requirements document. The 
additional project progress metrics thereby adding depth and accuracy to the analysis in 
the form of providing additional project progress metrics and data. The resultant 
analysis and assessment providing a more accurate and complete understanding of the 
progress of a project therefore assisting project managers with the critical management 
decisions regarding risk and quality during the life cycle of a project (Section 3 - 
Conclusion, Page 263). 

Regarding Claims 7, 15 and 26 Paul et al. does not teach outputting the data 
records to graphically represent the progress of a project. 

Minkiewicz et al. teaches the display of the project progress metrics and analysis 
such display providing the well-known benefit of ease of use (Figures 20-23). 
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It would have been obvious to one skilled in the art at the time of the invention 
that the method and system for analyzing and assessing the progress of a project, as 
taught by Paul et al., would have benefited from ease of use afforded to the end user by 
the graphically representation of project progress metrics in view of the teachings of 
Minkiewicz et al. 

Regarding Claims 8, 19 and 27 Paul et al. teaches a plurality of documents and 
project components for which project progress parameters are to be collected and 
analyzed. More specifically Paul et al. teaches the use of requirements and 
specifications the importance of the collection and analysis of metrics associated with 
those documents which Paul et al. refers to as requirements traceability and 
requirement stability metrics (Column 2, Paragraph 5, Page 256) 

Regarding Claim 9 Paul et al. teaches a method and system for analyzing and 
assessing the progress of a project as discussed above. Further Paul et al. in view of 
Minkiewicz et al. teaches the collection of a plurality of metrics and there associated 
data (data records) wherein the data is structured as trees (branches and leaves) as 
discussed above. 

Paul et al. does not teach the parsing of data during the production of data 
records. 
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Official notice is taken that it is old and well known in the art to represent data 
using tree data structures for expressing/storing that data in a standardized and 
structured format as discussed above. Further it is a well known a perquisite that 
representing and using data in structured formats, such as the DOM (tree), requires the 
ability to transform data into and out of (parsing) the chosen data representation before 
such a representation would be of any practical use. 

It would have been obvious to one skilled in the art at the time of the invention 
that the method and system for analyzing and assessing the progress of a project, as 
taught by Paul et al. and in view of the teachings o Minkiewicz et al., would have 
benefited the use of a the structured and standardized data structures as a means for 
transforming data; providing a structured means for collecting and analyzing project 
progress metrics. 

Regarding Claim 12 Paul et al. teaches the use of regression analysis as a 
means for assessing and analyzing project progress and trends (Paragraph 1, Page 
260). Paul et al. further teaches a method and system for assessing and analyzing the 
progress of a project wherein attention is paid to the resources to be allocated, having 
been allocated or available for a project are considered over time (Paragraph 4, Page 
256; Paragraph 2, Page 260; Conclusion, Page 263). 
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Paul et al. is silent on the frequency of the project progress assessments and 
forecasts. 

Official notice is taken that the frequency of assessing and analyzing the 
progress of a project is arbitrary and based on the individual preferences, 
legal/contractual project requirements, experiences, project size, scope and duration or 
any of a plurality other guidelines or schedules. Each assessment and analysis 
providing the user with an opportunity to make decisions related to the management of 
the projects progress, including the balancing of available and utilized resources. 

It would have been obvious to one skilled in the art at the time of the invention to 
utilize the method and system for analyzing and assessing the progress of a project as 
taught by Paul et al. in any desired frequency including but not limited to the daily 
project progress assessment and forecast, in view of the teachings of official notice, 
wherein the daily analysis and assessment would providing insight (forecasts) into a 
project progress and offer an opportunity to effect any of a plurality project progress 
parameters including the rebalancing of project resources on a daily basis thereby 
providing the user with an opportunity to make decisions and positively effect progress 
of a project. 

Regarding Claim 13 Paul et al. teaches the essentially temporal nature of the 
system and method for analyzing and assessing the progress of a project. More 



Application/Control Number: 09/760,339 Page 16 

Art Unit: 3623 

specifically Paul et al. teaches periodic queries (assessments) can provide timely and 
accurate information leading to good management decisions. Further Paul et al. 
teaches the dominant dimension of metrics data as being a temporal one (Section 1.1 - 
Simple Queries on Software Metrics, Page 255). 

Regarding Claim 14 Paul et al. teaches a plurality of techniques, including 
regression analysis, to identify the correlation among a plurality of metrics thereby 
determining their interdependencies as discussed above. 

Regarding Claim 18, claim 18 recites similar limitations to Claim land is therefore 
rejected using the same art and rationale as applied in the rejections of Claims 1 . 

7. Claims 5, 10, 11, 16,17 and 24 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Paul et al., Software Metrics Knowledge and Databases for Project 
Management (January 1999) in view of Lawler et al., U.S. Patent 5,930,798. 

Regarding Claims 5, 10, 1 1 and 24 Paul et al. teaches the use of a database to 
collect, store, read, write and analyze project progress parameters as discussed above. 

Paul et al. is silent on the architecture of the system and method disclosed arid 
does not expressly teach receiving data across a network. 
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Lawyer et al. teaches a network based method and system for analyzing and 
assessing the progress of a project; the network providing the ability to exchange data 
between different software applications and provide a consistent metric framework 
(Abstract). Further it is well known in the art that database systems are commonly built 
and deployed utilizing client/server or multi-tier architectures. The architecture of such 
systems being optimized for the sharing of resources and data across distributed 
systems/networks. 

It would have been obvious to one skilled in the art at the time of the invention 
that the method and system for analyzing and assessing the progress of a project as 
taught by Paul et al. would have benefited from the distributed system/network as 
taught by Lawyer et al. and gained the ability to exchange data between different 
software applications and provide a consistent metric framework (Abstract). 

Regarding Claim 16 Paul et al. is silent on the structure of the metric data stored, 
assessed or analyzed. 

Lawler et al. teaches a method and system for assessing and analyzing the 
progress of a project wherein the project's metrics (data records) are modeled as a set 
of measurement objects (Figure 11) wherein the use of the measurement object models 
allows for a consistent and repeatable measurement model (Abstract). 
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It would have been obvious to one skilled in the art at the time of the invention to 
model the data records (metrics) of the method and system for assessing and analyzing 
the progress of a project as taught by Paul et al. as objects in order to reap the benefit 
of creating a more consistent and repeatable means for manipulating and sharing 
metrics in view of the teachings of Lawler et al. 

Regarding Claim 17 Paul et al. is silent on the project's format. 

Lawler et al. teaches a method and system for assessing and analyzing the 
progress of a project wherein method and system is modeled using object-oriented 
format (Figures 1-17; Column 5, Lines 35-44). Further it is common for projects to 
utilize object-oriented languages, models, tools and techniques. Accordingly it would 
have been obvious to one skilled in the art at the time of the invention to express and 
manage the project as taught by Paul et al. utilizing object-oriented techniques, tools 
and languages as taught by Lawler et al. 

Official notice is taken that the use of content markup languages, XML for 
example, as a means of transmitting (exchanging) a wide variety of data on the 
distributed systems and elsewhere is well known in the art at the time of the invention. 
It is obvious the method for assessing and analyzing the progress of a project as taught 
by Paul et al. and further in view of the teachings of Lawler et al. (distributed network) 
would benefit from the simple and very flexible text format content markup languages 
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offer. Accordingly, it would have been obvious to one in the art at the time of the 
invention that the system and method for analyzing and assessing the progress of a 
project, as taught by Paul et al., would have benefited from the incorporation/use of 
content markup languages as a means of transmitting (exchanging) data over a 
distributed network and providing a standardized means for sharing of resources and 
data in view of the teachings of Minkiewicz et al. 



Conclusion 

The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 

- Carrier et al., U.S. Patent 5,960,196, teaches a software release metric 
reporting system and method wherein metrics are gathered from a software release 
control system which utilizes a version control subsystem to manage numerous 
versions of software modules or files developed. 

- Miller, U.S. Patent 6,101,481, teaches managing a software project using task 
management wherein relevant tasks within a project decomposed into a work 
breakdown structure (tree). 

- Parrish et al., U.S. Patent 5,553,282, teaches a distributed project history 
method and system wherein information concerning document (code, requirements 
document, and the like) versions are tracked in a historical database. 
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- Iwamoto at al., U.S. Patent 4,912,669, teaches a document editing system 
wherein the document has a basic tree structure wherein nodes (branches and leaves) 
represent the content and structure of the document. 

- Florae et al.. Measuring the Software Process: Statistical Process Control for 
Software Process Improvement, teaches the use of statistical process control (SPC) 
techniques can be used to manage and improve the software process. Florae et al. 
further teaches SPC related to project status and stability. 

- Weller, Using Metrics to Manage Software Projects, teaches the use of software 
metrics (including several metrics related to software requirement documents) in 
determining possible outcomes, which reflect that status of the project. 

- Daskalantonakis, A Practical View of Software Measurement and 
Implementation Experiences with Motorola, teaches the use of software metrics is 
greatly facilitated by a software configuration management system due to its ability to 
collect software metrics for analysis. Daskalantonakis further teaches the use of earned 
value and requirements tracking metrics. 

- Bohem et al.. Software Cost Estimation with COCOMO II, teaches an objective 
cost and schedule model for planning and executing software projects. Bohem further 
teaches the use of cost factors to model key process areas for a project including 
requirements management cost factors. 

- Nogueira et al., A Formal Risk Assesment Model for Software Evolution, 
teaches a formal method to asses the risk and duration of software projects that 
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includes tracing the evolution of requirements wherein the following metrics birth rate, 
death rate and change rate are used to measure the requirements volatility. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Scott L. Jarrett whose telephone number is (703) 305- 
0587. The examiner can normally be reached on 8:00AM - 5:00PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Hafiz Tariq can be reached on (703) 305-9643. The fax phone number for 
the organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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